Skip to main content

Last Update: 7/13/2025

Documentation Style Guide

This guide ensures consistency across all LLMProvider API documentation.

📝 General Guidelines​

1. File Structure​

  • All API docs should start with _Last Update: YYYY/MM/DD_
  • Use consistent heading levels: #, ##, ###
  • Include proper spacing between sections

2. Parameter Tables​

  • Use consistent column headers: Parameter, Type, Description
  • Mark optional parameters with (Optional) prefix
  • Include value ranges where applicable

3. Code Examples​

Tab Structure​

Always use this exact format for code tabs:

<Tabs>
  <TabItem value="shell" label="Shell" default>
    <!-- Shell example -->
  </TabItem>
  <TabItem value="nodejs" label="Node.js">
    <!-- JavaScript example -->
  </TabItem>
  <TabItem value="python" label="Python">
    <!-- Python example -->
  </TabItem>
</Tabs>

API Key Variables​

  • Use YOUR_API_KEY or $YOUR_API_KEY consistently
  • Never mix different variable formats in the same document

Model Names​

  • Use realistic, current model names in examples
  • Avoid deprecated model names
  • Ensure model names match the provider (e.g., gpt-4o for OpenAI, gemini-1.5-flash for Gemini)

4. Request/Response Format​

Headers Table​

| Header        | Value               |
|---------------|---------------------|
| Authorization | Bearer YOUR_API_KEY |
| Content-Type  | application/json    |

Parameter Naming​

  • Use tool_choice (not tools_choice)
  • Use max_tokens (not max_token)
  • Use temperature (consistent casing)

5. Common Mistakes to Avoid​

❌ Don't:

  • Add unnecessary parameters like conversation_id: '' to standard chat completions
  • Mix parameter names (tools_choice vs tool_choice)
  • Use incorrect model names for the provider
  • Forget to complete code examples
  • Use inconsistent indentation

✅ Do:

  • Test all code examples before publishing
  • Use consistent parameter names across providers
  • Include proper error handling in examples
  • Maintain consistent formatting
  • Update timestamps when making changes

6. Required Sections​

Every API document should include:

  1. Title with provider and feature name
  2. Endpoint with HTTP method and URL
  3. Request Headers table
  4. Request Body parameters table
  5. Example Request JSON
  6. Response Body description
  7. Example Response JSON
  8. Code Examples in Shell, Node.js, and Python

7. Error Handling​

Include basic error handling in all code examples:

Python:

if response.status_code == 200:
    print('Response:', response.json())
else:
    print('Error:', response.status_code, response.text)

JavaScript:

.then(response => {
    console.log('Response:', response.data);
})
.catch(error => {
    console.error('Error:', error);
});
  • Always include relevant external documentation links
  • Use descriptive link text
  • Ensure all links are functional

🔍 Review Checklist​

Before publishing any documentation:

  • All code examples tested and working
  • Parameter tables complete and accurate
  • Consistent formatting throughout
  • No spelling or grammar errors
  • Model names appropriate for provider
  • Error handling included in code examples
  • Links functional and relevant
  • Timestamp updated

For questions about this style guide, contact the documentation team.